Summary

• add opt-in DEVUP_UI_PROFILE=1 structured Turbopack timings for graph setup, production prewarm, coordinator extraction, snapshots, serialization, and writes
• reuse byte-identical production prewarm output in both singleCss and per-file mode, avoiding duplicate WASM extraction and duplicate snapshot/write work on repeated Turbopack loader requests
• keep polymorphic React inference exact while preventing redundant native-prop inference and duplicate intrinsic-prop conditionals
• ship a 1.18 MB lite extraction engine without Boa (71.8% smaller than the 4.19 MB full engine) and defer the Webpack adapter so Turbopack loads only the engine it needs
• conservatively translate fully static style({...}) .css.ts/.css.js modules to Devup css({...}) before extraction, allowing those builds to use the lite engine; variables, calls, spreads, extra statements, theme APIs, development mode, and source-map builds retain the full Boa engine
• make the existing benchmark.js comparison cold and order-balanced: clear .next, dist, df, and tsconfig.tsbuildinfo, use Turbopack for all three compared targets, alternate order, and report six-sample medians

No separate benchmark workflow was added. bun.lock remains unrelated and excluded. The add-bench PR was not touched.

Correctness boundary

The static fast path accepts only one style import and exported style() calls whose values are recursively static objects, arrays, strings, numbers, booleans, or null. Anything executable or unsupported fails closed to the existing full evaluator. Watch mode and production browser source maps always use full WASM. Public React declarations and theme inference are unchanged.

An actual production Turbopack build of the vanilla fixture selected wasmVariant:"lite"; its generated CSS matched the previous full build, prewarm extraction was 0.69 ms on the build config evaluation, and every loader request was a byte-identical cache hit with extractMs:0. An actual build after changing the fixture to use a local variable selected wasmVariant:"full" and also succeeded; that temporary fixture change was reverted.

Validation

• next-plugin: 126 passed, 0 failed; changed coordinator/static-transform sources report 100% function and line coverage
• next-plugin lint, TypeScript build, and bundled CJS/ESM entry builds pass
• full and lite WASM release builds, extractor/WASM/Rust checks, React TypeScript 6/7 inference checks, package/tarball checks, landing E2E, and Codecov passed on the preceding commits
• current CI benchmark job passed: https://github.com/dev-five-git/devup-ui/actions/runs/33231944233/job/99046168486

Existing benchmark.js CI results

All rows are six cold samples in the existing Publish workflow. Initial one-shot records are excluded from medians.

The optimized static .css.ts fixture is 30 ms faster by independent medians; the median of its six same-round Devup-minus-Tailwind deltas is about -20 ms. The ranges overlap, so the defensible conclusion is a narrow win/parity within CI-runner noise, not a universal performance victory. Dynamic .css.ts still takes the full Boa path; the prior fair run was 80 ms slower by independent medians, so this PR does not claim a dynamic-full victory.

Rejected experiments and benchmark limits

• reusing one Boa context was faster but broke per-file global isolation; a fresh Realm preserved semantics but more than doubled evaluator time, so neither change is included
• disabling Boa features saved only about 15 KB and could weaken compatibility; it is not included
• -O3 increased WASM size/package-build time and regressed the CI median; compact z/-Oz settings remain
• graph caching across Next's duplicate config evaluations was measured locally, but Next reloads the plugin module even in the same PID, so it produced no cache hit and was removed
• CSS/sheet/class/file serialization is below 1 ms in structured profiles, so batching/debouncing it is not a measured bottleneck

The fixtures are not semantically identical: Tailwind uses untyped class strings and emits framework CSS, while Devup validates typed style props and emits much less CSS. The benchmark is useful for regression/directional evidence, not proof that either library is always faster. Type checking and inference were deliberately not weakened.